home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 2: Applications / Linux Cubed Series 2 - Applications.iso / circuits / irsim-ca.2 / irsim-ca / irsim-cap-9.2 / man / irsim.doc < prev    next >
Text File  |  1990-12-23  |  40KB  |  901 lines

  1.                                                          IRSIM(1)
  2.  
  3. NAME
  4.      irsim - An event-driven logic-level simulator for MOS circuits
  5.  
  6. SYNOPSIS
  7.      irsim [-s] prm_file sim_file ... [+hist_file] [-cmd_file ...]
  8.  
  9. DESCRIPTION
  10.      IRSIM is an event-driven logic-level simulator for MOS (both
  11.      N and P) transistor circuits.  Two simulation models are
  12.      available:
  13.  
  14.      switch
  15.           Each transistor is modeled as a voltage-controlled
  16.           switch.  Useful for initializing or determining the
  17.           functionality of the network.
  18.  
  19.      linear
  20.           Each transistor is modeled as a resistor in series with
  21.           a voltage-controlled switch; each node has a capaci-
  22.           tance.  Node values and transition times are computed
  23.           from the resulting RC network, using Chorng-Yeoung
  24.           Chu's model.  Chris Terman's original model is not sup-
  25.           ported any more.
  26.  
  27.      If the -s switch is specified, 2 or more transistors of the
  28.      same type connected in series, with no other connections to
  29.      their common source/drain will be stacked into a compound
  30.      transistor with multiple gates.
  31.  
  32.      The prm_file is the electrical parameters file that config-
  33.      ure the devices to be simulated.  It defines the capacitance
  34.      of the various layers, transistor resistances, threshold
  35.      voltages, etc... (see presim(1)).
  36.      If prm_file does not specify an absolute path then IRSIM
  37.      will search for the prm_file as follows (in that order):
  38.  
  39.           1) ./<prm_file> (in the current directory).
  40.           2) ~cad/lib/<prm_file>
  41.           3) ~/cad/lib/<prm_file>.prm
  42.  
  43.      If ~cad/ does not exist, IRSIM will try to use directory
  44.      /projects/cad.  The default search directory (~cad) can be
  45.      overriden by setting the environment variable CAD_HOME to
  46.      the appropriate directory prior to running IRSIM (i.e.
  47.      setenv CAD_HOME /usr/beta/mycad).
  48.  
  49.      IRSIM first processes the files named on the command line,
  50.      then (assuming the exit command has not been processed)
  51.      accepts commands from the user, executing each command
  52.      before reading the next.
  53.  
  54.      File names NOT beginning with a '-' are assumed to be sim
  55.      files (see sim(5)), note that this version does not require
  56.      to run the sim files through presim.  These files are read
  57.      and added to the network database.  There is only a single
  58.      name space for nodes, so references to node "A" in different
  59.      network files all refer to the same node.  While this
  60.      feature allows one to modularize a large circuit into
  61.      several network files, care must be taken to ensure that no
  62.      unwanted node merges happen due to an unfortunate clash in
  63.      names.
  64.  
  65.      File names prefaced with a '-' are assumed to be command
  66.      files: text files which contain command lines to be pro-
  67.      cessed in the normal fashion.  These files are processed
  68.      line by line; when an end-of-file is encountered, processing
  69.      continues with the next file. After all the command files
  70.      have been processed, and if an "exit" command has not ter-
  71.      minated the simulation run, IRSIM will accept further com-
  72.      mands from the user, prompting for each one like so:
  73.  
  74.      irsim>
  75.  
  76.      The hist_file is the name of a file created with the dumph
  77.      command (see below).  If it is present, IRSIM will initilize
  78.      the network to the state saved in that file.  This file is
  79.      different from the ones created with the ">" command since
  80.      it saves the state of every node for all times, including
  81.      any pending events.
  82.  
  83.      This version supports changes to the network through the
  84.      update command.  Also, the capability to incrementally re-
  85.      simulate the network up to the current time is provided by
  86.      the isim command.
  87.  
  88.  
  89.  
  90. COMMAND SUMMARY
  91.      @ filename            take commands from command file
  92.      ? wnode...            print info about node's source/drain connections
  93.      ! wnode...            print info about node's gate connections
  94.      < filename            restore network state from file
  95.      > filename            write current network state to file
  96.      << filename           same as "<" but restores inputs too
  97.      | comment...          comment line
  98.      activity from [to]    graph circuit activity in time interval
  99.      ana wnode...          display nodes in analyzer window
  100.      analyzer wnode...     display nodes in analyzer window
  101.      assert wnode [m] val  assert that wnode equals val
  102.      back [time]           move back to time
  103.      c [n]                 simulate for n clock cycles (default:1)
  104.      changes from [to]     print nodes that changed in time interval
  105.      clock [node [val]]    define value sequence for clock node
  106.      clear                 clear analyzer window (remove signals)
  107.      d [wnode]...          print display list or specified node(s)
  108.      debug [debug_level..] set debug level (default: off)
  109.      decay [n]             set charge decay time (0 => no decay)
  110.      display [arg]...      control what gets displayed when
  111.      dumph filename...     write net history to file
  112.      exit [status]         return to system
  113.      flush [time]          flush out history up to time (default:now)
  114.      h wnode...            make node logic high (1) input
  115.      has_coords            print YES if transistor coordinates are available
  116.      inputs                print current list of input nodes
  117.      ires [n]              set incremental resolution to n ns
  118.      isim [filename]       incrementally resimulate changes form filename
  119.      l wnode...            make node logic low (0) input
  120.      logfile [filename]    start/stop log file
  121.      model [name]          set simulation model to name
  122.      p                     step clock one simulation step (phase)
  123.      path wnode...         display critical path for last transition of a node
  124.      print comment...      print specified text
  125.      printp                print a list of all pending events
  126.      printx                print all undefined (X) nodes
  127.      q                     terminate input from current stream
  128.      R [n]                 simulate for n cycles (default:longest sequence)
  129.      readh filename        read history from filename
  130.      report[level]         set/reset reporting of decay events
  131.      s [n]                 simulate for n ns. (default: stepsize)
  132.      stepsize [n]          set simulation step size to n ns.
  133.      set vector value      assign value to vector
  134.      setlog[file|off]      log net changes to file (off -> no log)
  135.      setpath               set search path for cmd files
  136.      stats                 print event statistics
  137.      t [-]wnode...         start/stop tracing of specified nodes
  138.      tcap                  print list of shorted transistors
  139.      time [command]        print resource utilization summary
  140.      u wnode...            make node undefined (X) input
  141.      unitdelay [n]         force transitions to take n ns. (0 disables)
  142.      update filename       read net changes from file
  143.      V [node [value...]]   define sequence of inputs for a node
  144.      vector label node...  define bit vector
  145.      w [-]wnode...         add/delete nodes from display list
  146.      wnet [filename]       write network to file
  147.      x wnode...            remove node from input lists
  148.      Xdisplay[host:n]      set/show X display (for analyzer)
  149.  
  150.      COMMAND DESCRIPTIONS
  151.  
  152.      Commands have the following simple syntax:
  153.  
  154.          cmd arg1 arg2 ... argn <newline>
  155.  
  156.      where cmd specifies the command to be performed and the argi
  157.      are arguments to that command.  The arguments are separated
  158.      by spaces (or tabs) and the command is terminated by a <new-
  159.      line>.
  160.  
  161.      If cmd is not one of the built-in commands documented below,
  162.      IRSIM appends ".cmd" to the command name and tries to open
  163.      that file as a command file (see "@" command).  Thus the
  164.      command "foo" has the same effect as "@ foo.cmd".
  165.  
  166.      Notation:
  167.  
  168.  
  169.      ...  indicates zero or more repetitions
  170.  
  171.      [ ]  enclosed arguments are optional
  172.  
  173.      node name of node or vector in network
  174.  
  175.      wnode
  176.           name of node or vector in network, can include '*'
  177.           wildcard which matches any sequence of zero or more
  178.           characters.  The pair of characters '{' and '}' denote
  179.           iteration over the limits enclosed by it, for example:
  180.           name{1:10} will expand into name1, name2 ... name10. A
  181.           3rd optional argument sets the stride, for example:
  182.           name{1:10:2} will expand into name1, name3, ... name7,
  183.           name9.
  184.  
  185.      | comment...
  186.           Lines beginning with vertical bar are treated as com-
  187.           ments and ignored -- useful for comments or temporarily
  188.           disabling certain commands in a command file.
  189.  
  190.      Most commands take one or more node names as arguments.
  191.      Whenever a node name is acceptible in a command line, one
  192.      can also use the name of a bit vector.  In this case, the
  193.      command will be applied to each node of the vector (the "t"
  194.      and "d" treat vectors specially, see below).
  195.  
  196.      vector label node...
  197.           Define a bit vector named "label" which includes the
  198.           specified nodes.  If you redefine a bit vector, any
  199.           special attributes of the old vector (e.g., being on
  200.           the display or trace list) are lost.  Wild cards are
  201.           not accepted in the list of node names since you would
  202.           have no control over the order in which matching nodes
  203.           would appear in the vector.
  204.  
  205.      The simulator performs most commands silently.  To find out
  206.      what's happened you can use one of the following commands to
  207.      examine the state of the network and/or the simulator.
  208.  
  209.      set vector value
  210.           Assign value to vector. For example, the following
  211.           sequence of commands:
  212.  
  213.                vector BUS bit.1 bit.2 bit.3
  214.                set BUS 01x
  215.  
  216.           The first command will define BUS to be a vector com-
  217.           posed of nodes bit.1, bit.2, and bit.3. The second com-
  218.           mand will assign the following values:
  219.  
  220.                bit.1 = 0
  221.                bit.2 = 1
  222.                bit.3 = X
  223.  
  224.           Value can be any sequence of [0,1,h,H,l,L,x,X], and
  225.           must be of the same length as the bit vector itself.
  226.  
  227.      d [wnode]...
  228.           Display.  Without arguments displays the values all
  229.           nodes and bit vectors currently on the display list
  230.           (see w command).  With arguments, only displays the
  231.           nodes or bit vectors specified.  See also the "display"
  232.           command if you wish to have the display list printed
  233.           out automatically at the end of certain simulation com-
  234.           mands.
  235.  
  236.      w [-]wnode...
  237.           Watch/unwatch one or more nodes.  Whenever a "d" com-
  238.           mand is given, each watched node will displayed like
  239.           so:
  240.  
  241.           node1=0 node2=X ...
  242.  
  243.           To remove a node from the watched list, preface its
  244.           name with a '-'.  If wnode is the name of a bit vector,
  245.           the values of the nodes which make up the vector will
  246.           be displayed as follows:
  247.  
  248.           label=010100
  249.  
  250.           where the first 0 is the value of first node in the
  251.           list, the first 1 the value of the second node, etc.
  252.  
  253.      assert wnode [mask] value
  254.           Assert that the boolean value of the node or vector
  255.           wnode is value.  If the comparison fails, an error mes-
  256.           sage is printed.  If mask is given then only those bits
  257.           corresponding to zero bits in mask take part in the
  258.           comparison, any character other than 0 will skip that
  259.           bit.  The format of the error message is the following:
  260.  
  261.                (tty, 3): assertion failed on 'name' 10X10 (1010X)
  262.  
  263.           Where name is the name of the vector, followed by the
  264.           actual value and the expected value enclosed in
  265.           parenthesis.  If a mask is specified, then bits that
  266.           were not compared are printed as '-'.
  267.  
  268.      ana wnode...
  269.           This is a shorthand for the analyzer command (described
  270.           below).
  271.  
  272.      analyzer wnode...
  273.           Add the specified node(s)/vector(s) to the analyzer
  274.           display list (see irsim-analyzer(3) for a detailed
  275.           explanation).  If the analyzer window does not exist,
  276.           it will be created.  If no arguments are given and the
  277.           analyzer window already exists, nothing happens.
  278.  
  279.      Xdisplay [host:display]
  280.           You must be able to connect to an X-server to start the
  281.           analyzer.  If you haven't set up the DISPLAY environ-
  282.           ment variable properly, the analyzer command may fail.
  283.           If this is the case you can use the Xdisplay command to
  284.           set it from within the simulator.  With no arguments,
  285.           the name of the current X-server will be printed.
  286.  
  287.      clear
  288.           Removes all nodes and vectors from the analyzer window.
  289.           This command is most useful in command scripts for
  290.           switching between different signals being displayed on
  291.           the analyzer.
  292.  
  293.      "?" and "!" allow the user to go both backwards and forwards
  294.      through the network.  This is a useful debugging aid.
  295.  
  296.      ? wnode...
  297.           Prints a synopsis of the named nodes including their
  298.           current values and the state of all transistors that
  299.           affect the value of these nodes.  This is the most
  300.           common way of wandering through the network in search
  301.           of what went wrong.
  302.           The output from the command ? out looks like
  303.  
  304.             out=0 (vl=0.3 vh=0.8) (0.100 pf) is computed from:
  305.             n-channel phi2=0 out=0 in=0 [1.0e+04, 1.3e+04, 8.7e+03]
  306.             pulled down by (a=1 b=1)  [1.0e+04, 1.3e+04, 8.8e+03]
  307.             pulled up [4.0e+04, 7.4e+04, 4.0e+04]
  308.  
  309.           The first line gives the node's name and current value,
  310.           its low and high logic thresholds, user-specifed low-
  311.           to-high and high-to-low propagation delays if present,
  312.           and its capacitance if nonzero.  Succeeding lines list
  313.           the transistor whose sources or drains connect to this
  314.           node: the transistor type ("pulled down" is an n-
  315.           channel transistor connected to gnd, "pulled up" is a
  316.           depletion pullup or p-channel transistor connected to
  317.           vdd), the values of the gate, source, and drain nodes,
  318.           and the modeling resistances.  Simple chains of
  319.           transistors with the same implant type are collapsed by
  320.           the -s option into a single transistor with a "com-
  321.           pound" gate; compound gates appear as a parenthesized
  322.           list of nodes (e.g., the pulldown shown above).  The
  323.           three resistance values -- static, dynamic high,
  324.           dynamic low -- are given in Kilo-ohms.
  325.  
  326.           Finally, any pending events for a node are listed after
  327.           the electrical information.
  328.  
  329.      ! wnode...
  330.           For each node in the argument list, print a list of
  331.           transistors controlled by that node.
  332.  
  333.      tcap
  334.           Prints a list of all transistors with their
  335.           source/drain shorted together or whose source/drain are
  336.           connected to the power supplies.  These transistors
  337.           will have no effect on the simulation other than their
  338.           gate capacitance load.  Although transistors connected
  339.           across the power supplies are real design errors, the
  340.           simulator does not complain about them.
  341.  
  342.      Any node can be made an input -- the simulator will not
  343.      change an input node's value until it is released.  Usually
  344.      on specific nodes -- inputs to the circuit -- are manipu-
  345.      lated using the commands below, but you can fool with a sub-
  346.      circuit by forcing values on internal nodes just as easily.
  347.  
  348.      h wnode...
  349.           Force each node on the argument list to be a high (1)
  350.           input.  Overrides previous input commands if necessary.
  351.  
  352.      l wnode...
  353.           Like "h" except forces nodes to be a low (0) input.
  354.  
  355.      u wnode...
  356.           Like "h" except forces nodes to be a undefined (X)
  357.           input.
  358.  
  359.      x wnode...
  360.           Removes nodes from whatever input list they happen to
  361.           be on.  The next simulation step will determine the
  362.           correct node value from the surrounding circuit.  This
  363.           is the default state of most nodes.  Note that this
  364.           does not force nodes to have an "X" value -- it simply
  365.           removes them from the input lists.
  366.  
  367.      inputs
  368.           prints the high, low, and undefined input lists.
  369.  
  370.  
  371.  
  372.      It is possible to define a sequence of values for a node,
  373.      and then cycle the circuit as many times as necessary to
  374.      input each value and simulate the network.  A similar
  375.      mechanism is used to define the sequence of values each
  376.      clock node goes through during a single cycle.
  377.  
  378.      Each value is a list of characters (with no intervening
  379.      blanks) chosen from the following:
  380.  
  381.           1, h, H     logic high (1)
  382.           0, l, L     logic low (0)
  383.           u, U        undefined (X)
  384.           x, X        remove node from input lists
  385.  
  386.      Presumably the length of the character list is the same as
  387.      the size of the node/vector to which it will be assigned.
  388.      Blanks (spaces and tabs) are used to separate values in a
  389.      sequence.  The sequence is used one value at a time, left to
  390.      right.  If more values are needed than supplied by the
  391.      sequence, IRSIM just restarts the sequence again.
  392.  
  393.      V [node [value...]]
  394.           Define a vector of inputs for a node.  After each cycle
  395.           of an "R" command, the node is set to the next value
  396.           specified in the sequence.
  397.  
  398.           With no arguments, clears all input sequences (does not
  399.           affect clock sequences however).  With one argument,
  400.           "node", clears any input sequences for that
  401.           node/vector.
  402.  
  403.      clock [node [value...]]
  404.           Define a phase of the clock.  Each cycle, each node
  405.           specified by a clock command must run through its
  406.           respective values.  For example,
  407.  
  408.                clock phi1 1 0 0 0
  409.                clock phi2 0 0 1 0
  410.  
  411.           defines a simple 4-phase clock using nodes phi1 and
  412.           phi2. Alternatively one could have issued the following
  413.           commands:
  414.  
  415.                     vector clk phi1 phi2
  416.                     clock clk 10 00 01 00
  417.  
  418.           With no arguments, clears all clock sequences.  With
  419.           one argument, "node", clears any clock sequences for
  420.           that node/vector.
  421.  
  422.      After input values have been established, their effect can
  423.      be propagated through the network with the following com-
  424.      mands.  The basic simulated time unit is 0.1ns; all event
  425.      times are quantized into basic time units.  A simulation
  426.      step continues until stepsize ns. have elapsed, and any
  427.      events scheduled for that interval are processed.  It is
  428.      possible to build circuits which oscillate -- if the period
  429.      of oscillation is zero, the simulation command will not
  430.      return.  If this seems to be the case, you can hit <ctrl-C>
  431.      to return to the command interpreter.  Note that if you do
  432.      this while input is being taken from a file, the simulator
  433.      will bring you to the top level interpreter, aborting all
  434.      pending input from any command files.
  435.  
  436.      When using the linear model (see the "model" command) tran-
  437.      sition times are estimated using an RC time constant calcu-
  438.      lated from the surrounding circuit.  When using the switch
  439.      model, transitions are scheduled with unit delay.  These
  440.      calculations can be overridden for a node by setting its
  441.      tplh and tphl parameters which will then be used to deter-
  442.      mine the time for a transition.
  443.  
  444.      s [n]
  445.           Simulation step.  Propogates new values for the inputs
  446.           through the network, returns when n (default: stepsize)
  447.           ns. have passed.  If n is specified, it will tem-
  448.           porarily override the stepsize value.  Unlike previous
  449.           versions, this value is NOT remembered as the default
  450.           value for the stepsize parameter.  If the display mode
  451.           is "automatic", the current display list is printed out
  452.           on the completion of this command (see "display" com-
  453.           mand).
  454.  
  455.      c [n]
  456.           Cycle n times (default: 1) through the clock, as
  457.           defined by the "clock" command.  Each phase of the
  458.           clock lasts stepsize ns.  If the display mode is
  459.           "automatic", the current display list is printed out on
  460.           the completion of this command (see "display" command).
  461.  
  462.      p    Step the clock through one phase (or simulation step).
  463.           For example, if the clock is defined as above
  464.  
  465.                clock phi1   1 0 0 0
  466.                clock phi2   0 0 1 0
  467.  
  468.           then "p" will set phi1 to 1 and phi2 to 0, and then
  469.           propagate the effects for one simulation step.  The
  470.           next time "p" is issued, phi1 and phi2 will both be set
  471.           to 0, and the effects propagated, and so on.  If the
  472.           "c" command is issued after "p" has been used, the
  473.           effect will be to step through the next 4 phases from
  474.           where the "p" command left off.
  475.  
  476.      R [n]
  477.           Run the simulator through n cycles (see the "c" com-
  478.           mand).  If n is not present make the run as long as the
  479.           longest sequence.  If display mode is automatic (see
  480.           "display" command) the display is printed at the end of
  481.           each cycle.  Each "R" command starts over at the begin-
  482.           ning of the sequence defined for each node.
  483.  
  484.      back time
  485.           Move back to the specified time.  This command restores
  486.           circuit state as of "time", effectively undoing any
  487.           changes in between.  Note that you can not move past
  488.           any previously flushed out history (see flush command
  489.           below) as the history mechanism is used to restore the
  490.           network state.  This command can be useful to undo a
  491.           mistake in the input vectors or to re-simulate the cir-
  492.           cuit with a different debug level.
  493.  
  494.      path wnode...
  495.           display critical path(s) for last transition of the
  496.           specified node(s).  The critical path transistions are
  497.           reported using the following format:
  498.  
  499.                node -> value @ time (delta)
  500.  
  501.           where node is the name of the node, value is the value
  502.           to which the node transitioned, time is the time at
  503.           which the transistion occurred, and delta is the delay
  504.           through the node since the last transition.  For exam-
  505.           ple:
  506.  
  507.                critical path for last transition of Hit_v1:
  508.                     phi1-> 1 @ 2900.0ns , node was an input
  509.                     PC_driver-> 0 @ 2900.4ns    (0.4ns)
  510.                     PC_b_q1-> 1 @ 2904.0ns    (3.6ns)
  511.                     tagDone_b_v1-> 0 @ 2912.8ns    (8.8ns)
  512.                     tagDone1_v1-> 1 @ 2915.3ns    (2.5ns)
  513.                     tagDone1_b_v1-> 0 @ 2916.0ns    (0.7ns)
  514.                     tagDone_v1-> 1 @ 2918.4ns    (2.4ns)
  515.                     tagCmp_b_v1-> 0 @ 2922.1ns    (3.7ns)
  516.                     tagCmp_v1-> 1 @ 2923.0ns    (0.9ns)
  517.                     Vbit_b_v1-> 0 @ 2923.2ns    (0.2ns)
  518.                     Hit_v1-> 1 @ 2923.5ns    (0.3ns)
  519.  
  520.      activity from_time [to_time]
  521.           print histogram showing amount of circuit activity in
  522.           the specified time inteval.  Actually only shows number
  523.           of nodes which had their most recent transition in the
  524.           interval.
  525.  
  526.      changes from_time [to_time]
  527.           print list of nodes which last changed value in the
  528.           specified time interval.
  529.  
  530.      printp
  531.           print list of all pending events sorted in time.  The
  532.           node associated with each event and the scheduled time
  533.           is printed.
  534.  
  535.      printx
  536.           print a list of all nodes with undefined (X) values.
  537.  
  538.      Using the trace command, it is possible to get more detail
  539.      about what's happening to a particular node.  Much of what
  540.      is said below is described in much more detail in "Logic-
  541.      level Simulation for VLSI Circuits" by Chris Terman, avail-
  542.      able from Kluwer Academic Press.  When a node is traced, the
  543.      simulator reports each change in the node's value:
  544.  
  545.                [event #100] node out.1: 0 -> 1 @ 407.6ns
  546.  
  547.      The event index is incremented for each event that is pro-
  548.      cessed.  The transition is reported as
  549.  
  550.           old value -> new value @ report time
  551.  
  552.      Note that since the time the event is processed may differ
  553.      from the event's report time, the report time for successive
  554.      events may not be strictly increasing.
  555.  
  556.      Depending on the debug level (see the "debug" command) each
  557.      calculation of a traced node's value is reported:
  558.  
  559.       [event #99] node clk: 0 -> 1 @ 400.2ns
  560.        final_value( Load )  V=[0.00, 0.04]  => 0
  561.        ..compute_tau( Load )
  562.           {Rmin=2.2K  Rdom=2.2K  Rmax=2.2K}  {Ca=0.06  Cd=0.17}
  563.           tauA=0.1  tauD=0.4 ns
  564.       [event #99: clk->1] transition for Load: 1 -> 0 (tau=0.5ns, delay=0.6ns)
  565.  
  566.      In this example, a calculation for node Load is reported.
  567.      The calculation was caused by event 99 in which node clk
  568.      went to 1.  When using the linear model (as in this example)
  569.      the report shows
  570.  
  571.           current value -> final value
  572.  
  573.      The second line displays information regarding the final
  574.      value (or dc) analysis for node "Load"; the minimun and max-
  575.      imum voltages as well as the final logical value (0 in this
  576.      case).
  577.  
  578.      The next three lines display timing analysis information
  579.      used to estimate the delays.  The meaning of the variables
  580.      displayed can be found Chu's thesis: "Improved Models for
  581.      Switch-Level Simulation".
  582.  
  583.      When the final value is reported as "D", the node is not
  584.      connected to an input and may be scheduled to decay from its
  585.      current value to X at some later time (see the "decay" com-
  586.      mand).
  587.  
  588.      "tau" is the calculated transition time constant, "delta" is
  589.      when any consequences of the event will be computed; the
  590.      difference in the two times is how IRSIM accounts for the
  591.      shape of the transition waveform on subsequent stages (see
  592.      reference given above for more details).  The middle lines
  593.      of the report indicate the Thevenin and capacitance parame-
  594.      ters of the surrounding networks, i.e., the parameters on
  595.      which the transition calculations are based.
  596.  
  597.      debug [ev dc tau taup tw spk][off][all]
  598.           Set debugging level.  Useful for debugging simulator
  599.           and/or circuit at various levels of the computation.
  600.           The meaning of the various debug levels is as follows:
  601.  
  602.           ev      display event enqueueing and dequeueing.
  603.  
  604.           dc      display dc calculation information.
  605.  
  606.           tau     display time constant (timing) calculation.
  607.  
  608.           taup    display second time constant (timing) calculation.
  609.  
  610.           tw      display network parameters for each stage of
  611.                   the tree walk, this applies to dc, tau, and
  612.                   taup.  This level of debugging detail is usu-
  613.                   ally needed only when debugging the simulator.
  614.  
  615.           spk     displays spike analysis information.
  616.  
  617.           all     This is a shorthand for specifying all of the
  618.                   above.
  619.  
  620.           off     This turns off all debugging information.
  621.  
  622.           If a debug switch is on then during a simulation step,
  623.           each time a watched node is encounted in some event,
  624.           that fact is indicated to the user along with some
  625.           event info.  If a node keeps appearing in this prinout,
  626.           chances are that its value is oscillating.  Vice versa,
  627.           if your circuit never settles (ie., it oscillates) ,
  628.           you can use the "debug" and "t" commands to find the
  629.           node(s) that are causing the problem.
  630.  
  631.           Without any arguments, the debug command prints the
  632.           current debug level.
  633.  
  634.      t [-]wnode...
  635.           set trace flag for node.  Enables the various printouts
  636.           described above.  Prefacing the node name with '-'
  637.           clear its trace flag.  If "wnode" is the name of a vec-
  638.           tor, whenever any node of that vector changes value,
  639.           the current time and the values of all traced vectors
  640.           is printed.  This feature is useful for watching the
  641.           relative arrival times of values at nodes in an output
  642.           vector.
  643.  
  644.      System interface commands:
  645.  
  646.      > filename
  647.           Write current state of each node into specified file.
  648.           Useful for making a breakpoint in your simulation run.
  649.           Only stores values so isn't really useful to "dump" a
  650.           run for later use, i.e., the current input lists, pend-
  651.           ing events, etc. are NOT saved in the state file.
  652.  
  653.      < filename
  654.           Read from specified file, reinitializing the value of
  655.           each node as directed.  Note that network must already
  656.           exist and be identical to the network used to create
  657.           the dump file with the ">" command.  These state saving
  658.           commands are really provided so that complicated ini-
  659.           tializing sequences need only be simulated once.
  660.  
  661.      << filename
  662.           Same as "<" command, except that this command will
  663.           restore the input status of the nodes as well.  It does
  664.           not, however, restore pending events.
  665.  
  666.      dumph [filename]
  667.           Write the history of the simulation to the specified
  668.           file, that is; all transistions since time = 0.  The
  669.           resulting file is a machine-independent binary file,
  670.           and contains all the required information to continue
  671.           simulation at the time the dump takes place.  If the
  672.           filename isn't specified, it will be constructed by
  673.           taking the name of the sim_file (from the command line)
  674.           and appending ".hist" to it.
  675.  
  676.      readh filename
  677.           Read the specified history-dump file into the current
  678.           network.  This command will restore the state of the
  679.           circuit to that of the dump file, overwriting the
  680.           current state.
  681.  
  682.      flush [time]
  683.           If memory consumption due to history maintanance
  684.           becomes prohibitive, this command can be used to free
  685.           the memory consumed by the history up to the time
  686.           specified.  With no arguments, all history up to the
  687.           current point in the simulation is freed.  Flushing out
  688.           the history may invalidate an incremental simulation
  689.           and the portions flushed will no longer appear in the
  690.           analyzer window.
  691.  
  692.      setpath [path...]
  693.           Set the search-path for command files.  Path should be
  694.           a sequence of directories to be searched for ".cmd"
  695.           files, "." meaning the current directory.  For eaxmple:
  696.  
  697.               setpath . /usr/me/rsim/cmds /cad/lib/cmds
  698.  
  699.           With no arguments, it will print the current search-
  700.           path.  Initially this is just ".".
  701.  
  702.      print text...
  703.           Simply prints the text on the user's console.  Useful
  704.           for keeping user posted of progress through a long com-
  705.           mand file.
  706.  
  707.      logfile [filename]
  708.           Create a logfile with the specified name, closing
  709.           current log file if any; if no argument, just close
  710.           current logfile.  All output which appears on user's
  711.           console will also be placed in the logfile.  Output to
  712.           the logfile is cleverly formatted so that logfiles
  713.           themselves can serve as command files.
  714.  
  715.      setlog [filename | off]
  716.           Record all net changes, as well as resulting error mes-
  717.           sages, to the specified file (see "update" command).
  718.           Net changes are always appended to the log-file,
  719.           preceding each sequence of changes by the current date.
  720.           If the argument is off then net-changes will not be
  721.           logged.  With no arguments, the name of the current
  722.           log-file is printed.
  723.  
  724.           The default is to always record net changes; if no
  725.           filename is specified (using the "setlog" command) the
  726.           default filename irsim_changes.log will be used.  The
  727.           log-files are formatted so that log-files may them-
  728.           selves be used as net-change files.
  729.  
  730.      wnet [filename]
  731.           Write the current network to the specified file.  If
  732.           the filename isn't specified, it will be constructed by
  733.           taking the name of the sim_file (from the command line)
  734.           and appending ".inet" to it.  The resulting file can be
  735.           used in a future simulation run, as if it were a sim
  736.           file.  The file produced is a machine independent
  737.           binary file, which is typically about 1/3 the size of
  738.           the sim file and about 8 times faster to load.
  739.  
  740.      time [command]
  741.           With no argument, a summary of time used by the simula-
  742.           tor is printed.  If arguments are given the specified
  743.           command is timed and a time summary is printed when the
  744.           command completes.  The format of the time summary is
  745.           Uu Ss E P% M, where:
  746.  
  747.           U => User time in seconds
  748.           S => System time in seconds
  749.           E => Elapsed time, minutes:seconds
  750.           P => Percentage of CPU time (((U + S)/E) * 100)
  751.           M => Median text, data, and stack size use
  752.  
  753.      q    Terminate current input stream.  If this is typed at
  754.           top level, the simulator will exit back to the system;
  755.           otherwise, input reverts to the previous input stream.
  756.  
  757.      exit [n]
  758.           Exit to system, n is the reported status (default: 0).
  759.  
  760.      Simulator parameters are set with the following commands.
  761.      With no arguments, each of the commands simply prints the
  762.      current value of the parameter.
  763.  
  764.      decay [n]
  765.           Set decay parameter to n ns. (default: 0).  If non-
  766.           zero, it tells the number of ns. it takes for charge on
  767.           a node to decay to X.  A value of 0 implies no decay at
  768.           all.  You cannot specify this parameters separately for
  769.           each node, but this turns out not to be a problem.  See
  770.           "report" command.
  771.  
  772.      display [-][cmdfile][automatic]
  773.           set/reset the display modes, which are
  774.  
  775.           cmdfile     commands executed from command files are
  776.                       displayed to user before executing.  The
  777.                       default is cmdfile = OFF.
  778.  
  779.           automatic   print out current display list (see "d"
  780.                       command) after completion of "s" or "c"
  781.                       command.  The default is automatic = ON.
  782.  
  783.           Prefacing the previous commands with a "-" turns off
  784.           that display option.
  785.  
  786.      model [name]
  787.           Set simulation model to one of the following:
  788.  
  789.           switch
  790.             Model transistors as voltage controlled switches.
  791.             This model uses interval logic levels, without
  792.             accounting for transistor resistances, so circuits
  793.             with fighting transistors may not be accuratelly
  794.             modelled.  Delays may not reflect the true speed of
  795.             the circuit as well.
  796.  
  797.           linear
  798.             Model transistors as a resistor in series with a
  799.         voltage controlled switch.  This model uses a
  800.         single-time-constant computed from the resulting RC
  801.         network and uses a two-time-constant model to analyze
  802.         charge sharing and spikes.
  803.  
  804.           The default is the linear model.  You can change the
  805.           simulation model at any time -- even with events pend-
  806.           ing -- as only new calculations are affected.  Without
  807.           arguments, this command prints the current model name.
  808.  
  809.      report [level]
  810.           When level is nonzero, report all nodes which are set
  811.           to X because of charge decay, regardless on whether
  812.           they are being traced.  Setting level to zero disables
  813.           reporting, but not the decay itself (see "decay" com-
  814.           mand).
  815.  
  816.      stepsize [n]
  817.           Specify duration of simulation step or clock phase. n
  818.           is specified in ns. (nanoseconds).  Floating point
  819.           numbers with up to 1 digit past the decimal point are
  820.           allowed.  Further decimals are trucated (i.e. 10.299 ==
  821.           10.2).
  822.  
  823.      unitdelay [n]
  824.           When nonzero, force all transitions to take n ns.  Set-
  825.           ting the parameter to zero disables this feature.  The
  826.           resolution is the same as for the "stepsize" command.
  827.  
  828.      stats
  829.           Print event statitistics, as follows:
  830.  
  831.                changes = 26077
  832.                punts (cns) = 208 (34)
  833.                punts = 0.79%, cons_punted = 16.35%
  834.                nevents = 28012; evaluations = 27972
  835.  
  836.           Where changes is the total number of transistions
  837.           recorded, punts is the number of punted events, (cns)
  838.           is the number of consecutive punted events (a punted
  839.           event that punted another event).  The penultimate line
  840.           shows the percentage of punted events with respect to
  841.           the total number of events, and the percentage of con-
  842.           secutive punted events with respect to the number of
  843.           punted events.  The last line shows the total number of
  844.           events (nevents) and the number of net evaluations.
  845.  
  846.      Incremental simulation commands:
  847.  
  848.      Irsim supports incremental changes to the network and
  849.      resimulation of the resulting network.  This is done incre-
  850.      mentally so that only the nodes affected by the changes,
  851.      either directly or indirectly, are re-evaluated.
  852.  
  853.  
  854.      update filename
  855.           Read net-change tokens from the specified file.  The
  856.           following net-change commands are available:
  857.  
  858.           add     type gate source drain length width [area]
  859.           delete  type gate source drain length width [area]
  860.           move    type gate source drain length width [area] g s d
  861.           cap     node value
  862.           N       node metal-area poly-area diff-area diff-perim
  863.           M       node M2A M2P MA MP PA PP DA DP PDA PDP
  864.           thresh  node low high
  865.           Delay   node tplh tphl
  866.  
  867.           For a detailed dscription of this file see netchange(5).
  868.           Note that this is an experimental interface and is
  869.           likely to change in the future.
  870.  
  871.           Note that this command doesn't resimulate the circuit
  872.           so that it may leave the network in an inconsistent
  873.           state.  Usually this command will be followed by an
  874.           isim command (see below), if that is not the case then
  875.           it's up to the user to initilize the state of the cir-
  876.           cuit.  This command exists only for historical reasons
  877.           and will probably disappear in the future.  It's use is
  878.           discouraged.
  879.  
  880.      isim [filename]
  881.           Read net-change tokens from the specified file (see
  882.           netchange(5)) and incrementally resimulate the circuit
  883.           up to the current simulation time (not supported yet).
  884.  
  885.      ires n
  886.           The incremental algorithm keeps track of nodes deviat-
  887.           ing from their past behavior as recorded in the network
  888.           history.  During resimulation, a node is considered to
  889.           deviate from its history if it's new state is found to
  890.           be different within n ns of its previous state.  This
  891.           command allows for changing the incremental resolution.
  892.           With no arguments, it will print the current resolu-
  893.           tion.  The default resolution is 0 ns.
  894.  
  895. SEE ALSO
  896.      presim(1) (now obsolete)
  897.      rsim(1)
  898.      irsim-analyzer(3)
  899.      sim(5)
  900.      netchange(5)
  901.